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ABSTRACT 

It  is  mportant  for  the  program  Manager  to  understand 
the  software  life-cycle  and  development  process.  Multiple 
■odels  of  the  life-cycle  are  examined  and  compared  with  the 
DOD  software  life-cycle.  The  Rayleigh  equation  and  the 
resulting  difficulty  gradient  equation  of  the  SLId  software 
model  are  very  powerful  techniques  for  estimating  develop- 
ment time,  effort,  and  cost.  To  estimate  the  size  of  the 
new  project  a  Bayesian  inference  technique  is  proposed.  This 
technique  is  tnen  applied  using  the  SLIM  model  and  the  QS"! 
data   base. 
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I.     IMTBODBCTIOH 

This  thesis  is  an  attempt  to  understand  the  software 
cost  estimating  process  as  viewed  by  a  program  manager 
daring   the   early  phases  of  system  development. 

Software  cost  estimators  have  problems  because  of  their 
inability  to  estimate  the  size  of  new  programs. 
Historically- based  methods  are  difficult  to  use  because  the 
estimator  is  unable  to  assess  skills,  tools,  complexity,  and 
environment  of  past  developments  and  of  the  new  software. 
The  results  are  severe  cost  overruns,  schedule  slippage,  and 
lack   of  credibility.      [Ref.    1] 

In  software  estimating  models,  software  size  is  the  key 
parameter  influencing  cost.  All  the  proven  estimating  tech- 
niques begin  with  an  estimate  of  the  size  of  the  software 
package  and  then  at  various  levels  of  sophistication  produce 
an  estimate  of  cost  or  time  based  on  size  and  calculated  or 
derived    productivity   factors. 

A  quick,  reliable  estimate  of  size  could  provide  a 
better  cost  estimate  for  planning  purposes.  The  program 
manager's  concern  is  time,  cost,  and  performance  of  the 
total  svstea.  Re  needs  to  present  this  information  to  higher 
DOD    management   levels   during    the   early   planning    phase. 

This  paper  is  an  investigation  of  ways  in  which  an  esti- 
mator may  be  ifcie  to  estimate  the  size  of  a  new  project, 
based  on  an  existing  data  base  of  close  to  1,000  systems. 
Breakouts  have  been  made  of  that  data  base  by  application 
type  and  the  average  size  and  the  standard  deviation  or  each 
of  these  applications  is  calculated.  In  the  early  phase  of 
system  development,  a  reasonable  goal  would  be  to  estimate 
time  within  15  percent  and  effort  within  30  percent  of 
actual. 
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The  prograa  manager  should  hare  a  detailed  understanding 
of  the  process  that  developed  the  cost  estiaate  and  should 
have  sose  traceability  to  the  variance  or  sensitivity  of  the 
estimating  component.  The  use  of  automated  software  models 
for  estimating  has  become  popular  in  industry  and  . DOD. 
Prograa  managers  can  compare  different  rodels  for  alterna- 
tive  estimates. 

Ill  the  variables  of  the  software  equation  are  subject 
to  soae  degree  of  uncertainty  and  the  prograa  manager  must 
have  a  means  of  taxing  this  into  account  in  an  effort  to 
development  risk  profiles.  Putnam  [fief.  2]  suggests  that 
risk  analysis  is  probably  the  most  important  aspect  c£  any 
software  systea  analysis.  In  an  uncertain  process,  risk 
analysis  measures  that  uncertainty.  This  leads  to  strat- 
egies tc  minimize  risk.  The  prograa  manager  should  perform 
risk  analysis  and  determine  the  probability  of  aeeting 
schedule/cost . 

This  paper  uses  SLIM  (Software  Life-cycle  Management) . 
The  SLIM  model  uses  soae  of  the  aost  powerful  tools  of  anal- 
ysis available  today  —  linear  programming,  Monte  Carlo 
simulation,  and  algorithms  from  the  PERT  methodology  —  to 
produce  the  best  possible  solution  to  the  software  esti- 
mating   problem.      [Bef.    1] 

The  prograa  aanager  predicts  and  controls  schedule  and 
costs.  It  is  important  for  the  program  manager  to  recognize 
potential  probleas  early  and  take  effective  corrective 
action. 
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II.   3&TX3U2  Mgfcfilttl  AM  CU£ifi£fl£]il  £&fi££§2 

The  software  life-cycle  may  be  said  to  start  in  the 
perception  of  a  need  and  to  terminate  when  the  system  is 
retired  as  obsolete.  The  program  manager  has  the  responsi- 
bility froi  start  to  end  for  the  project.  The  program 
manager  must  understand  the  software  life-cycle  and  its 
development  process.  A  lack  of  understanding  or  the  process 
of  software  development  (activities,  phases,  and  milestones) 
causes  a  poor  estimate.  The  software  development  process 
can    be    subdivided   into   seguential  and   overlapping   phases. 

Figure  2.  1  [Ref.  2]  depicts  the  total  system  milestones 
in  relationship  with  four  software  cost  models  considered. 
The  DOD  subdivides  the  life  cycle  of  an  automated  informa- 
tion system  into  five  broad  phases:  [Ref.  3]  Mission 
Analysis  Project  Initiation,  Concept  Development,  Definition 
Design,    System   Development,    Deployment   Operation. 

Putnam  [F.ef.  u]  divides  it  as:  Systems  definition. 
Functional  design  specification.  Development (design  and 
coding,  test  and  validation).  Operation  and  maintenance. 
The   development    process  is  divided   as    follows. 

PDR  -  preliminary  Design  Review.  This  is  the  earliest 
time  that  a  formal  review  of  the  functional  design  specifi- 
cations can  be  expected  to  be  satisfactory  enough  tc 
continue  into  the  next  phase  of  development.  Functional 
design  and  (high  level)  system  engineering  is  essentially 
complete. 

CDR  -  Critical  Design  Review.  This  is  a  review  of  the 
detailed     logic    design      for    each      element      of   system.  The 

design   consists    of    flow   charts,    HIPO1    diagrams.      Pseudo-code 


lHIEO  (Hierarchy-Prccess-Inpat-Out put)  was  developer,  at 
IBn  as  design  representation  schemes  for  top-down  software 
development  and  contained  a  visual  table  of  contents,  a  set 
of   overview    overview    diagrams,    and   a   set   of   detail   diagrams. 
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Figure   2.1        Software   Life-Cycle. 

logic,  or  equivalent.  It  is  held  when  design  and  coding  are 
separated  by  management  decision  as  by  SI L  STD  (military 
standards).  Coding  cannot  start  until  after  a  successful 
CDB  under  this  philosophy.  There  lust  be  sufficient  design 
to   start  coding. 

FCC  -  Pirst  Code  Complete.  In  a  top-down,  structured 
design  and  coding  environment,  FCC  is  the  tine  at  which  all 
the  units  of  code  have  been  written,  the  units  have  been 
peer  and  management  checked,  successfully  coapiled  and  run 
as  units,  and  thought  to  be  satisfactory  end  product  code. 
It  is  then  entered  into  a  library  of  completed  code.  (Note: 
coding    will   continue    thereafter  as   rework   of    these    modules.) 
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SIT  -  Systems  Integration  Test.  This  is  the  earliest 
time  that  ail  elements  and  subsystems  have  been  put  together 
and  the  systen  can  work  together  as  a  complete  integrated 
package   and    can   demonstrate    that    in    a    formal   system   test. 

U0S1-  User  Oriented  System  Test.  Pclloving  correction  of 
deficiencies  resulting  from  SIT,  00 ST  is  the  first  time  that 
a  test  of  the  system  in  a  full  user  environment  —  target 
machine  and  operating  system,  real  data,  real  operating 
conditions   --   can   be   conducted. 

IOC  -  Initial  Operational  Capability  or  start  of  instal- 
lation, depending  on  the  environment.  This  is  a  careful, 
tentative  first  use  under  rigid  control.  Often  this  is  a 
first  site  installation  in  a  live  environment  with  antici- 
pated later  multi-site  deployment,  or  the  start  of  operation 
in  parallel  uitn  the  predecessor  system  in  a  single  site 
replacement    environment. 

FOC      -    Full     Operational    Capability.  Here    the     system 

meets  specified  quality  standards  sufficiently  ve^l  that 
organizations  will  use  it  in  everyday  routine  mission  opera- 
tions. (In  SIIH,  that  is  a  95  percent  reliability  level; 
calibration  and  technology  factors  are  normalized  to  this 
reliability    level.) 

Boehm  [Ret.  5]  divides  the  cycle  into  feasibility,  plans 
and  requirements,  product  design,  programming,  integration 
and  test,  and  maintenance.  The  primary  emphasis  of  his 
COC01O*  model  is  on  the  development  portion  of  the  life- 
cycle  which  CCCC«C  defines  as  starting  ••  at  the  beginning  of 
the  product  design  phase  and  ending  at  the  end  of  the  soft- 
ware integration  and    test   phase   ".      [Ref.    5] 


2C0nstr uctive  COst  lOdel,  a  hierarchy  of  three  increas- 
ingly detailed  models  (  basic,  intermediate.  detail)  which 
canqe  from  a  single  macro- estimation  scaling  model  as  a 
function  of  product  size  to  a  micrc-estimation  model  with  a 
three-level  work  breakdown  structure  and  a  set  of  phase- 
sensitive   multipliers   for   each   cost    driver   attribute. 
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The  PBICE-S  software  model  is  one  of  the  'amily  of  RCA 
cost  predicting  lodels.  PBICE-S  divides  the  software  devel- 
opment cycle  into  three  phases:  design,  implementation,  and 
test   and  integration. 

The  guestion  facing  the  program  aanager  is  what  to 
invest  in  and  what  is  its  payoff.  Boeha  [  Ref .  5]  developed 
a  value-of-inf oriation  guideline  with  the  following  five 
conditions: 

1.  There   exist  attractive   alternatives   whose   payoff  varies 
greatly,    depending   on  some  critical  state   of    nature. 

2.  The  critical   states   of    nature   have  an   appreciable 
probability  of   occuring. 

3.  The   investigations   have    a   high    probability   of 
accurately   identifying    the  occurrence   of  critical 
states    of    nature. 

4.  The  required  cost   and  schedule   of   the    investigations 
do   not    overly   curtail  their   net    value. 

5.  There   exist  significant    side   benefits    derived   frotn 
performing    the   investigations. 

The  major  difficulty  with  these  guidelines  is  deter- 
mining what  arc  the  critical  states  of  nature.  Boehi  implies 
some  of  these  states  in  his  definition  of  feasibility  phase 
and    plans   and    requirements   phase   [Bef.    5]: 

Feasibility  phase:  How  auch  should  we  invest  in  informa- 
tion system  (user  questionnaires  and  interview  ,  current- 
system  analysis,  woricload  characterizations,  simulations, 
scenarics,  prototypes)  in  order  that  we  converge  on  an 
appropriate  definition  and  concept  of  operation  for  the 
system    we   plan    tc   implement? 

Plans  and  requirements  phase:  How  rigorously  should  we 
specify  requirements?  How  much  should  we  invest  in  require- 
ments validation  activities(  automated  completeness,  consis- 
tency, and  traceacility  checks,  analytic  r.odels, 
simulations,      prototypes)         before    proceedinq    to      design   and 
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develop  a  software  system?  It  is  important  for  the  program 
aanager    to    know    the  early    phases  of   systea  developaent. 

Boeba  [  Ref.  6]  points  out  the  uncertainty  of  cost  esti- 
aation  during  the  early  project  phase.  Fig  2.2  shows  the 
accuracy  within  vhicb  software  cost  estimation  can  be  made, 
as  a  function  of  the  software  life-cycle  phase  ,or  of  the 
level  of  knowledge  we  have  of  what  the  software  is  intended 
to  do.  At  the  beginning  of  the  feasibility  phase,  the  rela- 
tive range  of  software  cost  estimates  is  roughly  a  factor  of 
four3  on  either  the  high  or  low  side  which  is  not  surprising 
based  on  the  limited  knowledge  available  at  this  point.  The 
estiaation  uncertainty  is  reduced  to  from  .5  to  2  after  the 
concept  of  operation  has  been  defined,  After  completion  of  a 
requirement  specification,  the  estiaation  range  is  .67  to 
1.5.  Gradually,  the  estiaation  range  becomes  smaller  until 
we   finally    arrive  at   acceptance. 

Fairley's  [ Bef .  7]  suggested  life-cycle  approach  divides 
into  four  aodels:  The  phased,  model,  cost  model,  prototype 
life-cycle   model,        and  successive      versions   model.  Costs 

incurred  within  each  phase  include  the  cost  of  performing 
the  process  and  preparing  the  products  for  that  phase,  plus 
the  cost  of  verifying  that  the  products  of  the  present  phase 
are  complete  and  consistent  witn  respect  tc  all  previous 
phases.  Fairley  also  suggests  there  are  some  reasons  for 
developing  a  prototype:  (1)  to  illustrate  input  data 
foraats,  message,  reports  ,  and  interactive  dialogues  for 
the  customer;  (2)  to  explore  technical  issues  in  the 
proposed  product;  and  (3)  in  situations  where  the  phased 
codel  or  analysis  ->  design  ->  iaplementation  is  not  appro- 
priate. Product  development  by  the  method  of  successive 
versions  is  an  extension  of  prototyping  in  wnich  an  initial 
product      skeleton     is      refined     into     increasing      levels     of 


3The  ranges  are  intended  to  represent  BO  percent  confi- 
dence limits,  that  is  ,  ••  within  a  factor  of  four  cr  either 
side,    80   percent  of   the   time." 
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Pigure   2.2        Software  Cost   Bstiaation   Accuracy    vs.    Phase. 

capability. 

PutDaa  [Bcf.    3]     suggests   that   a      good    life      cycle    aodel 
should    possess   these  characteristics: 

1.  Consider  all  activities    and   phases. 

2.  Relate    aanageaent   paraseters  to  aanageaeat 
responsibilities. 

3.  Be  adaptive   to  actual   proiect  data  and   requi resents 
changes (   i.e.    sust  be  tiae- varying  or   dynaaic) 

4.  Provide   engineering   accuracy. 

5.  Provide    sensitivity    profiles. 

6.  8e  phenoaenologically  based. 

7.  Belate   produce  to   resource  consusption    (both   statically 
and  dynaaically)    the  technology   being  applied. 

8.  Be  capable   or    future   growth. 

9.  Be   able    to   adequately  treat    tnown  and   future   systea 
types   and  deveiopsent   environaents. 
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Software  life  cycle  and  development  processes  offer  a 
structured  jeans  for  planning,  developing,  and  controlling 
the  software  project.  Boeha  [fief.  9]  suggests  that  the 
tradeoffs  between  lower  development  costs  and  lower  life 
cycle  costs  are  characterized  by  the  aodern  progra using 
practice  and  required  reliability  cost  estimating  relation- 
ships fcr  software  development  and  maintenance.  The  program 
manager  must  understand  the  software  life-cycle  and  develop- 
aent process  cf  multiple  models  and  compare  with  DOD  life- 
cycle.  The  program  lanager  must  predict  and  control  schedule 
and  costs.  Also  tne  program  manager  must  recognize  poten- 
tial problems  early  and  take  effective  corrective  action.  It 
is  important  for  the  program  manager  to  minimize  the  cost/ 
schedule  impact   of    requirements  changes. 
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in.  5SJIA4IIIG  lMSMMlSOU  AJB  SflSX  msiigTB  factors 

In  order  for  the  program  manager  and  his  support  team 
to  evaluate  a  software  cost  proposal,  they  oust  have  a 
detailed  understanding  of  the  process  that  developed  the 
cost  estiiate  and  should  have  some  traceability  to  the  vari- 
ances  or  sensitivity    of   the   estimating   components. 

The  object  of  software  cost  estimation  is  to  determine 
what  resources  (manpower,  computer  time,  and  elapsed  time) 
will  be  needed  to  produce  the  software  associated  with  the 
project.  Stanley  [fief.     10]     listed    some      reasons    for      not 

obtaining  a    gcod  estimate   as: 

1.  A    lack    of   understanding    of   the    process   of    software 
de  velopment. 

2.  A    lack    of    understanding    of    the   effects   of    various 
technical    and      management  constraints. 

3.  A    view    of    that   each    project   is    unique,    whicc 
inhibits    project    to    project   comparisons. 

4.  A    lack    of    historical   data  against    which   the   model 
car   be    checked  and    for    calibration. 

Boeha  [Rcf.  5]  suggests  that  a  good  software  model 
should    possess    the    following    characteristics: 

1.  Definition:    Can   you    tell    what   it    is  estimating? 
Kill  different  people  give  similar   factor   rating? 

2.  Pidelity:    Are   the   actuals  close   tc   the   estimates? 

3.  Detail:    Does   it   give    (accurate)    phase   and   activity 
br  takdovns? 

u.   Constr ucti veness:    Can   you   tell    why   it    gives   the 
estimates   it    does?    Does    it   help   ycu   understand   the 
software    job? 

5.  Objectivity:    Is    it   hard    to   jigger   the    model    to   gst 
any  result    you   want? 

6.  Stability:    Do   small    input  changes    produce    small   output 
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changes? 
7.    Scope:    Does  the   aodel  cover   your   class  of  software 

project? 
a.    Easy  to    use:   Are   the   sodel  inputs,    and  outputs   easy   to 

understand   aad  specify? 
9.   Prospectiveness:    Does  it   depend  on  information   not 

known    until   later? 

10.  Parsimony:    Does  it   use   redundant   or   unnecessary 
factors? 

11.  Availability:    Can   I    get    access   to   the   aodel? 

The  prograa  aanager  coapares  various  cost  models  for 
alternative  estimates.  The  sodel  should  allow  for  the  use 
of  historic  data  in  calibration  for  a  particular  organiza- 
tion and  type  of  software.  k  good  software  cost  estimation 
aodel  should  cover  software  engineering  issues  which  arise 
throughout    the   software  life    cycle. 

A.       TECHNIQUES 

According  tc  Stanley  [Bef.  10],  most  cost  models  use  one 
or  both  of  the  following  eguations.  The  first  is  called  the 
cost  eq  uatior  : 


b 
E     *    a  «  S 

where  E  -  effort  r.teded,  s  ■  size  of  program  is  terms  of 
some  Measure  of  lines  of  code  and  a  and  b  are  chosen  by 
curve  fitting  on  a  historical  database.  Different  values  of 
a  and  b  are  appropriate  to  different  organizations,  project 
types,  units  of  measurement  of  E  and  S,  and  items  include! 
in   the    the    estimates. 

The     second     equation      is     called      the      general     summing 
equation: 

n 
2      *      I      af      =    a   f      ♦   a   f      ♦    ♦    a    f 

i=1      i   i  1    1  2    2  n   n 


20 


where  the  a.  are  input  parameters  derived  froa  the  descrip- 
tion of  software  characteristics  and  the  characteristics  of 
the  development  environment,  and  the  value  of  f;  are  chosen 
by  curve  fitting  on  a  suitable  historic  database.  Table  1 
[ Ref .  7  ]  shows  a  comparison  of  effort  and  development  time 
equations  according  to  software  size.  Some  models  provide 
equations  to  estimate  total  man  months  of  effort.  MM,  in 
terms  of  the  number  of  thousands  of  delivered  source 
instructions,  KDSI.  Also  the  development  time  for  software 
project,  TDZV,  measured  in  terms  of  MM.  A  software  project's 
cost  can  be  obtained  by  multiplying  tne  effort  in  man  months 
by  the    cost    per    man   month. 


TABLE    1 
COHPABISOI   OF    EFFORT    AID    TIHE    EQOATIOMS  [Pe  f .     7J 

Effort   equation  Development    time  Author 

MM  =  TDEV  »  | 

5.2  (KDSI)  **0. 9  I        2.  47  (MM)  **0.35        aalston    j 
4.9  (KDSI)  **0. 98        3.04  MS  **0.36        Nelson     | 


1.5  (KDSI)  **1.02  4.38 
2.4  KDSI)  **1.05  2.50 
3.0  (KDSI)  **1.12  2.50 

3.6  (KDSI)  **1. 20  2.50 
1.0  KDSI)  **1.40 


MM 
Ml 
MM 
M3 


**0.25        Freburger 

**0.38  Soehn 

**0.35  Boehn 

**0.32  Boehm 

Jones 


0.7  (KCSI)  **1.50  -  Hal3tead 

28    (KDSI)**  1.83  -  Schnieder 


Thibodeau  [Ref.    11]  states  that    parametric   models  may   be 
divided    into   three  classes: 

1.  Regression  model:  The  parameters  to  be  estimated  are 
mathematically  related  tc  a  set  of  input  parameters. 
The  parameters  of  the  hypothesized  relationships  are 
arrived  at  by  statistical  analysis  and  curve  fitting 
on  an   appropriate   historical   database. 

2.  Heuristic   acdels:    Here    observation  and   interpretation 
of   historic  data   are   combined   with  supposition   and 
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experience. 
3.    Phenomenological   model:    This  is  based   on  a    hypothesis 
that  the   software  development    process   can   be   explained 
in    tecas   of  some   more  widely  applicable   process  or 
idea. 

The  first  model  class  seems  tc  be  the  approach  used  in  most 
ccst   modelinq.  This  class    includes    the      Aerospace,       Doty, 

Farr,  Zagorski,  and  Telecote  lodels.  The  second  model  class 
seems  to  be  the  type  used  in  preparing  a  proposal  where 
detailed  UBS  elements  are  prepared  and  summed  for  the  total 
cost.  The  Eoeing  and  PRICE  S  models  along  with  the  DOD 
HICBO  Procedure  and  the  Wolverton  model  aave  been  termed 
heuristic.  An  example      of    the      last    class      is   the     Putnax 

model.      [Sef.    11] 

Stanley  [fief.  10]  suggests  a  general  pattern  followed  by 
all   the    models: 

1.  Estimate   software  size 

2.  Convert    size  estimate  to   labor   estimate 

3.  Ad  lust    estimate   for    special   project  characteristics 
m.    Divide    the   total   estimate  into    the   different    project 

ph  ases 

5.  Estimate   non- technical    labor   costs 

6.  Sum   the    cost 

.lost  models  start  from  an  estimate  of  project  size.  Soae 
models  convert  from  size  to  labor,  others  go  directly  from 
size  to  money  estimates.  The  effective  estimate  is  an 
adjustment  of  the  basic  estimate  intended  to  take  account  or 
any  special  project  characteristics  which  make  it  dissimilar 
to  the  pattern  absorbed  in  the  underlying  historic  database. 
Each  model  which  deals  with  a  project* s  schedule  makes 
assumptions  about  the  allocation  of  effort  in  different 
project  phases. 


22 


B.       SOHB    SPBCiriC   TECHMIQOES 

Proi  the  CS3*  data  base,  we  per for a  cuct«  fitting  to  get 
the  relationship  of  software  size  versus  derelopaent  tise 
and  effort  using  the  regression  aethod.  Despite  the  vide 
ranges,  the  developsent  tise  and  effort  correlate  very  well 
with  the  nuafcer  of  source  statenents.  Figure  3.1  shows 
size  versus   developsent   tise   fros   the  curve-fitting     sethod. 


Mixed  Application  Data  Base 


^1098 


10009  00 


Figure  3.1    QSB  Database)  Software  Sise  ?••  Developeent  Tise. 

To  estisate  software  size*  the  PEST*  sethod  is  suggested. 
The  PEB*  equations  estiaate  the  expected  size  (ES)  and  stan- 
dard deviation  (  6    )    ot  each  subsystes  as 


ES   -   (  a  ♦  «a  ♦  b  )  /  6 
1        i     1    i 


*i"   (bi  "  *i  '  /   6 


where 


•Quantitative  Software  ttanageaent.    Inc. 
•Prograa    Evaluation  and    Review   Technigue. 
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a  *  the  lowest  possible  size  of  the  software  subsystem 

■  *  the  eost  likely  size  of  the  sutsystea 

i 

b  *  the  highest  possible  size  of  the  subsystem 

i 

The   estimated   total   software    size    (S)    and  standard   deviation 

(4?S)  are  then 


n  /    n  \  1/2 

S      *       I  ES  .  &S 

i*1  i 


(M-r 


This  PEBT  sizing  technique  requires  sore  work  to  break  up 
the  software  into  subsystems  and  to  estimate  most  likely 
size  for  each  subsystem  as  well  as  to  eliminate  upper  and 
lower  lxsits.  PERT  estimates  should  be  made  by  knowledge- 
able software  designers,  preferably  those  who  will  do  the 
specific  work. 

C.      COSI   AITBIBOTE    FACTORS 

Stanley      [Ref.    10]  defines     two   major     area   of     software 
cost   drivers:  project   specific      factors  and      organization 

dependent  factors.  Boehm  [  Ref.  9]  identifies  five  facto,  a 
which  closely  match  Stanley's.  Size  attributes,  program 
attributes  and  computer  attributes  fall  into  Stanley's 
project  specific  factor.  Personnel  attrinutes  and  project 
attributes  fall  into  Stanley's  organization-dependent 
factors.  Holverton  [Ref.  121  suggests  that  top-level  char- 
acteristics are  parameters  which  can  be  classified  into 
software  structural  parameters  and  project  financial  parame- 
ters. Sortware  structural  parameters  say  be  divided  size, 
program  attributes,  hardware  attributes,  project  attributes, 
environmental  attributes.  Project  financial  parameters  are 
divided  into  direct  labor  charges,  overnead,  other  direct 
charge,    general   and  administrative   expense,    and    fee. 
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Brae*  and  Pederson  [fief.  13]  divide  cost  drivers  into 
four  categories:  requirement  factors,  product  factors, 
process  factors,   and   resource  factors. 

Two  factors  that  can  hare  a  aajor  impact  on  the 
ultimate  cost  of  a  software  product  arc  (1)  the  quality  of 
the  specifications   and    (2)    the  stability  of   tne   reguirement. 

a.  Quality  of   Specifications 

A  good  definition  of  requirements  is  the  corner- 
stone of  a  well-defined,  well-understood,  and  well-costed 
software  development.  Incomplete  requirement  definition  is  a 
aajor   cause   of   cost   overruns. 

b.  Stability   of    Requirements 

Ihe  responsibility  of  the  project  manager  is  to 
understand  the  software  requirements  and  to  point  out  that 
changes      in      the     requirement  baseline     are     changes.  The 

Fcoject  manager   should  then    define      the  cost   and/or   schedule 
impact    so   that   the  change   can   be   given   a  fair   evaluation. 

2.      Ecgdjici   factors 

a.  Software   Size 

A  favorite  measure  for  software  system  size  is 
lines  of  operational  code  or  deliverable  code.  Parametric 
cost  estimating   models     relate  cost    in  some  way      to   the    size 

estiaat «. 

b.  Difficulty 

After  considering  the  relative  lifficolty  of 
various  software  systems  and  functions,  the  cost  estimator 
must  consider  the  difficulty  of  the  specific  application  and 
its  heritage  tc  complete  the  analysis  of  the  difficulty 
factor. 
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a.  Management   Structure 

Management  structure  incorporates  the  effects  of 
various  company  policies  with  respect  to  allocating  costs 
for  certain  non-project  manageaent  personnel  as  a  direct 
charge    to  projects. 

b.  Management  Control 

This  covers  the  cost  of  project  support  in  such 
areas  as  management  information  processing,  scheduling 
support,  administrative  support,    and  clerical   support. 

c.  Development   Methods 

This  factor  attempts  to  quantify  the  impact  of 
various  development  methods.  The  development  metaods  of 
interest  include  such  approaches  as  top-down  design  and 
testing,  structured  programming,  use  of  chief  programmer 
teams,    and   use   of   the   structured    wa lie- through s. 

d.  Tools 

The  program  manager  must  consider  now  the  soft- 
ware will  be  developed,  tested,  and  maintained  and  what 
tools  will  be  needed  to  accomplish  these  tasks.  Por  systems 
developed  for  large-scale  computer,  a  host  of  compiler,  data 
base  managers,  editors,  display  interface  package,  flow 
chart  package,  plot  package,  utility  routines,  and  test  data 
generation  tools  are  generally  available.  The  costs  associ- 
ated with  tools  are  a  function  of  the  tool  complexity,  use, 
features,    and,    maturity. 

e.  Available  Software 

1  significant  reduction  in  project  can  be 
achieved  through  the  use  of  existing  software.  The  costs  of 
modifying  the  existicg  software  can  then  be  determined 
sub  ject  ivel y. 
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f.      Data   Base 

The  size,  complexity,  and  special  file  access 
requirements  for  the  data  base  are  extresely  ixportant 
parameters  in  deriving  an  accurate  software  development 
estimate. 

4.      JMflMCJ  TZSX9LS 

Development  costs  for  a  given  software  package  may 
vary  substantially,  depending  on  such  factors  as  experience 
of  available  people,  guality  of  project  staff,  and  avail- 
ability of    development  computer   resources. 

a.  Muster  of    People 

The  major  contributor  to  the  reduction  in 
productivity  associated  vith  projects  that  require  larger 
staffs  is  the  increase  in  time  needed  for  communication 
between   people. 

b.  Experience   of  People 

The  program  manager  must  consider  the  general 
level  of  experience  and  skill  required  for  various  project 
assignment  and  incorporate  appropriate  labor  rates  into  the 
estimate. 

c.  Personnel    Performance 

Since  software  development  is  an  analytical, 
sometimes  creative  activity  requiring  abstract  reasoning, 
individual  productivity  variations  are  to  be  expected. 
Productivity  assessment  is  extremely  important  because  cost 
estimation  generally  is  reduced  to  deriving  a  productivity 
figure  per  unit  of  effort  per  person  for  a  given  skill 
categor  y. 
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d.  availability  of  cotputinq   Resources 

For  batch  develop  tent  systets  there  is  t  linear 
relationship  between  turnaround  tiae  and  testing  costs.  For 
iateractivs  dovelopesat  systets,  significant  dtvelopsstit 
efficiencies   are  often  realised. 

e.  Suitaoility   of  Cotputinq    P*  sources 

The  asytptotic  offset  on  developter.t  costs  as 
the  hardware  speed  and  tenor  y  sits  constraints  arc 
approach**  has  been  de ton st rated  in  batch,  real-tiae, 
airborau,    ailitary,   and  coatercial   systos. 

f.  Elapsed  Tits 

Ths  aaoeat  ot  calsndsr  tite  available  to  develop 
a  software  prodtct  is  ittitattly  related  to  ths  altitats 
develop  tent  ccst.  Beloe  ths  threshold,  the  increased  staff 
required  to  accomplish  ths  job  it  a  shorter  period  has  the 
opposite  of    the   desired  effort. 

Table  2  [Ret.  6  1  shoes  the  various  site,  proqraa, 
coaputer,  personnel,  atd  prefect  attributes  used  by  each 
aodel    tc    latere  ice   software   ccsts. 

Muterout  factors  itfluencs  the  cost  of  a  software 
develop  eertt  proiect  atd  each  should  be  evaluated  dunnu  cost 
sttitatior.  to  ensure  that  proper  veiqhtinq  is  applied  to  the 
cost  estisates.  Current  sodels  differ  it  the  factors  that 
are  required  as  specific  inputs.  Nany  different  factors  tay 
ue  subseted  in  a  single  parateter  it  sose  nodels,  particu- 
larly the  tod**,  subjective  parateters.  The  proqraa  tana^er 
should  tstess  existing  personnel/facility  resources  and 
detertine  future  require tet ts.  fclso  ths  proqraa  aanaqer 
neaseret  owrkeed  and  detersite  the  efficiency  of  resource 
allocations    ic   nultiple  devsloptent    task   projects. 
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It  is  iapcrtant  for  the  program  aanager  to  develop  reli- 
able estimates  by  perfcraing  parallel  calculations  on 
■ultiple   aodels. 
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IV.    Silfl 

The  SLIH  eodel  is  a  comprehensive  software  cost  esti- 
mating package  produced  by  Quantitative  Software  Hanagement 
Inc.  SLIH    is     an  aid     for      effectively   managing     software 

development.  Using  engineering  techniques,  SLIH  provides 
cost,  time,  personnel,  and  machine  estimates  for  developing 
coaputer     software        systems-  SLIH        identifies      limiting 

constraints      that     affect      development      plans.  Confidence 

levels  and  risk  factors  are  calculated  to  provide  the 
manager  with  the  data  needed  to  make  decisions  on  cost, 
schedule,  effort,  quality,  aanloading,  and  cash  flow.  The 
SLIH  ,  software  costing  and  management  system  does  these 
things   [der.    2]: 

1.  Determines    the  size    of    the  system   in  source   statements 

2.  Estimates   the   people,  cost   and    schedule  for   the  project 

3.  Projects   cashflow   over    the  life  cycle 

a.    Identifies    limiting   constraints   on  manpower   and 
schedule 

5.  Obtains    risk   projections   for  cost   ana  schedule 

6.  Updates    estimates    from    the   real   data    once   development 
is   underway 

7.  Dynamically  adjusts    for    requirements  changes   to  give 
new  cost   and   schedule 

The  SLl.i  model  is  claimed  to  be  valid  for  any  systea 
where   at   least    two   of    the    following    four  criteria   apply: 

1.  5000   lines    cf   code   or  greater 

2.  $100,000   or   sore    in    development   costs 

3.  Pea*   manpower    cf    3    people   or   more 

<*.    Development    time   of    6  months    or   longer 

Over  sixty  large  organizations  such  as  DOD,  IBM,  and  GIZ 
have  used  the  SLIM  package.  SIIN'fl  accuracy  has  been  teste! 
for   over  1300   systems  of    all      types   in   the   United  States  and 
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6.   Bayleigh   management    paraieters    can   be   easily   turned 
into  a    linear   program  with   iaportant   aanageaent 
constraint (manpower,    cost,    schedule)    properly 
considered     to      yield     constrained     optiaal      solutions. 
Figure    4.1    [Bex.    2]  shows   the   Bayieigh   function    as  a  manage- 
ment  tool. 


manpower 


Y 


SLOPE 


MANPOWER   BUILDUP  RATE   (K/t/) 

Q 


xy  •  INCREMENTAL  MANPOWER 


•     INCREMENTAL  TIME 


MANPOWER    AT   ANY    TIME 


Figure    4.1         Bayieigh    Function  as   Software    Management   Tool. 

The     Bayieigh  eguation      is     linearized      by   talcing      loga- 
rithms, 

Ln(y/t)    *    Ln  (K   /      t  »)    ♦    f-t  /  2   t   »  )         t*      . 

d  d 

3pon  plotting  tnis  eguation  in  terms  cf  manpower  applied  to 
a  systee  over  tiee  squared,  a  straight  line  is  provided  in 
which  Ln(  It  /  td»  )  is  the  intercept  and  (  -1  /  2  t^*  )  is 
the  slope.  Patnas  [ Bef .  81  perforied  this  operation  for  one 
hundred  systeis  and  found  that  the  argument  of  the  intercept 
(      *   /      t    2)  has      a   most      interesting    property.  Putnam 
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[Rsf.  1]  suggests  that  ths  ratio  k  /  t^«  rsprsssntsd  ths 
difficulty,  D,  in  tsrss  of  ths  progressing  sffoct  and  ths 
tiss   to  pro  dues  it.   By  takiag  ths  gradisnt  of   d,    hs  gsts 


17  D|    ■      K/      t    >    •  constant 
d 

This  difficulty  gradisat  rsflscts  ths  organizational  capa- 
bility la  doing  that  typs  of  work  for  which  ths  constaat  was 
dsriwsd.  Thi  difficulty  in  ths  dstslopssnt  of  ths  softwara 
verlss  lnvsrssly  with  ths  talus  of  the  gradisnt,  i.e,  ths 
aost  difficult  projscts  bar*  ths  ssallsst  gradisnt.  Proa 
obssrwatlon,  Putnaa  [Rsf.  21  suggssts  | 7  0  |  is  guaatizsd  at 
ths  following  levsls:  7.3  for  nsw  dsvslopaant*  with  intsr- 
facss  to  othsr  prograas;  14.7  for  a  nsw  staad-alona  dsvslop- 
asat  projscts  26.9  for  a  rs- building  of  an  sxistiag  prograa; 
55.0  for  a  coapusits  eyatsal;  aad  89.0  for  a  conpoaits 
systss2     containing     auch  siistiag      cods.  Thsss     waluas's 

uncsrtaiaty  la  about  15  psrcsnt  of  ths  bass  value.  Whan  ths 
difficulty  is  plottsd  agaiast  productivity  rata,  PR*,  for  « 
nuabsr  of  systsaa,    Putnaa   gsts  ths  relationship 

-2/3 
PR    •  C      0 

n 

C     ■  produetifity  constant 
n 

Ths  arsa  undsr  tha  coding  rats,  S.,  curvs?  is  ths  total 
quantity  of  final  sad  product  sourcs  statsssats  that  will  bs 
produesd  by  tlsa  t  [Rsf.  5%  That  is,  sourcs  statsssnts  ar« 
produced  during  tha  dsslgn  and  coding  subcycls  of  Raylelgn 
curvt-.  Thus,  ths  intsgral  of  th"  aanpowsr  rats  for  this 
subcycla  eultlplied  by  ths  productivity  <jiwis  sourcw  state- 
asnts.        Proa  th4  abo?s  reesoos,      putnaa  [Rsf.    1]  dsvwlopa  a 


•total   and   ptoduct  coat  /   total   sffort   to  producu  co<U 
'Productivity  rats    *     eanrowr     ■    PR    ■    i 
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mathematical  relationship,  the  SLia  software  equation,  vbich 
is  an  powerful  tool  for  planning  and  evaluating  the  develop- 
■ent  effort    life  cycle.      The    software   equation   is: 


i,  •  (i,  .  «•  .  <fi  .  ;,   .  *»  .  rc  .   jJL.  .   t   .   •■•(^fi\.   -i 


1/3        a/3 
S      »    C  K  t 

s  k  d  . 

S   »  nuiber  of  delivered  source  instructions 

s 

C   *   state  of   technology  constant 

k 

K,    t     is   equivalent   to   Bayleigh  eguation   parameters 

d 

Putnaa  [fief.  15]  observed  that  the  tine  at  which  the 
Bayleign  curve  reaches  its  aaiisua  value,  t<j  ,  corresponds 
to  the  tiae  cf  systea  testing  and  product  release  for  aany 
software  products.  That  is,  normally  peak  manpower,  T  sax, 
exists    as  a    function   of  developaent    tiae(t(j), 

i  ■      k    /  JT  t      • 

sax  d 

The  area  under  the  Bayleigh  curve  interval  represents  the 
total  effort  expended  in  that  interval.  Approximately  forty 
percent  of  the  area  under  the  Bayleigh  curve  is  to  the  left 
of  t a  and  sixty  percent  is  to  the  right.  By  rearranging  the 
software  equation  and  applying  a  factor  ox  .4  to  reflect 
that  the  development  effort,  E,  is  approximately  the  first 
forty   percent  of   the   life  cycle  curve. 


!,SY)     ■    .4K    ■    .4     |        s\        /         t 
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B?  applying  tha  burdanad  labor  rat*  (  avaraga  dollar 
coat  par  aao  yaar  or  aan  Booth  of  of  fort),  th*  agitation 
changaa   to   coat 


alopaant   coat  •      (    I  /      (1Y)    .  u        /     a  \        /        t 


I.       0ICIITAII1T    AIALY9X9 

a 

Alaoat  atary  factor  antarlng  into  an  aatlaata  of  aifort 
and  achadula  la  aubjact  to  aeaa  dagraa  of  uncartalnty.  Tha 
aanagar  naada  to  portray  tha  affacta  of  tha  uncartalfcty 
aaaoclatad  with  a«tch  of  thaaa  factora.  To  gat  a  raaaonabla 
aatlaata  of  uncartalnty  In  llfa-cycla  affort  and  davalopaant 
tlaa,  Nonta  Carlo  aiaulatlon  la  uaad*  Ultan  C^,  S_ ,  tf*s  , 
|VD|,  andtf|7D|,  Patnaa  [laf.  21  obtalnad  atatlatloa  on 
variabllty  of  tha  aifort  and  davalop  tlaa  froa  aavaral  thou- 
aaad  aaaplaa.  Froa  tha  SLIH  aof tura*  agaatlon  and  tha  diffi- 
culty gradlant  aguatloa,    «a  daks  tha  aguatlon  aa   followat 


■ .  &-) 


1  /    1 


d 

Mao   tha  attndaid  daflatun    (    €  t  ^  ,  4t     )    obtalnad   L'roa   a 

Honta  carlo    aiaulatlon     will    ba  uaad  to  aaka  a  rlah  analyala 

proflla.     <in     API  prograa     for  thla  aiaulatlon   analyala     of 

aatlaatlng   davalopaant   tlaa,    affort,  and  tha  aajor   allaatona 
tlaa   la   aiionn    In   rlgura   4.2. 
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N  COMPUTE  INPUT; XX ;YY;TD;K; BAR ;KK 
TO  COMPUTE  DEVELOPMENT  EXPECTED  TIME  AND  EFFORT. 
12  CQ«f.yi|  STANDARD  DEVIATION  OF  TIME  AND  EFFORT 
TO  GENERATE  THE  MAJOR  MILESTONE  OF  THE  PROJECT. 


simulation  running  number, 
technology  constant. 
software  size  mean. 
Software  Size  standard  dev. 
difficulty  gradient  mean, 
difficulty  gradient  standard  dev. 
random  number  genertors  for 

size  and  difficulty  gradient. 
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INPUT  2  , 
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SOFTWARE 
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Figure   4.2        APL   Prograa   foe   Development   Tiae   and   Effort. 

Linear  programming  is  used  to  obtain  the  two  aost  inpor- 
tant  answers  in  software  development  projects-minimum  tiao 
and  siniaaa  ccst.  These  "best  possible"  solutions  also  boend 
the  range  of  reasonable  solutions  -  all  feasible  solutions 
lie  in  between  these  extreaes  and  are  explicitly  identified. 
The  linear  prograaaing  (L? )  approach  has  another  great 
advantage.  It  produces  constrained  optiaal  solutions.  The 
SLI.l  aodel  has  introduced  the  aost  iaportant  software 
aanageaent  constraints  —  maxiaua  cost,  reguired  delivery 
txae,  and  staffing  capability  —  into  the  problem.  This 
gires   the   prograa   aanager   real  control      in   his  own   domain   of 


37 


resource  allocation  and  control  [Ref.    2].      The  equations  for 
tee  LP    formulation   are  as  follows: 


1/3      a/3 
S     ■     C         K  t  software  equation 

SI  d 


R  /   t        <  7e~    X  maximum   peak   manpower 

d      ■  sax 


R  /  t        >  JT    I  miniium  peak   aanpover 

d     ■  sin 

2 
R  /  t  <      |0|  aaxiauB  difficulty 

d 


R  /  t  <      17  0   1  aaxiaua  difficulty  gradient 

d 


t        <        contract    delivery    tiae 

d      - 


(J  /    HI)     (    .4   K  )    <   total   budgeted   amount   for   development 


These  can  be  solved  with  graphic  or  simplex  aethods. 
Figure  4.3  shows  LP  graphical  feasibility  solution  usin^ 
LOG-LOG    tiaasforma  tion   plot.       [Ref.    2] 

C.       AVAILABLE    OPTIONS 

The  SLI.1  function  routine  is  composed  of  three  options: 
top-level,  what-ir  option,  and  implementation  option. 
Figure   4.4    shews  the   SLIM    acthodology.      [Ref.    4] 
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The  top-level  fuactlona  in  SLIM  includes  Cell brate 
input,  crojact  input,  end  project  eatlaate.  The  proceee  by 
which  •  aodai  la  tailored  to  t  particular  citii  of  ayataae 
with  tho  intent  of  liking  it  a  bottoc  prodictor  it  called 
calibration.  It  la  important  for  tht  trocraa  aanau«r  to  try 
to  tailor  hit  lodtl  Croa   hit   paat  data. 

a.  calibrate  Input 

Allows  user  to  calibrate  hiatoric  projecta  Cor 
productivity   and  aeapover  buildup  indeiea. 

b.  Project  Input 

Proapta  uaer  Cor  all  project  eatiaate  inforae- 
tion  and  bullda  or  aodlCiea  project  date  Cilea. 

c.  Project  latiaete 

Pcovldea  all  coat,  achedulc,  aanpouer,  quality 
and  riak  eatieetee  Cor  a  aoCtvere  project.  Once  a  ainiaua 
tlae  aolutlon  baa  been  eatebliehed  the  aenegeaent  vhet-lC 
optiona  can  be  ueed  to  lapooe  project  oonatrainta.  then  an 
acceptanle  aclution  la  choaen  tbe  lapleaeatatioa  optiona  cau 
cenerate  a  conalatent  aet   cf    work  plana. 

3.      Euaiill  fiAUflA 

It  la  iaportant  Cor  tbe  prooraa  aenaaer  to  try 
aenaltivity  analyala.  Ualeaa  it  ia  eaaential  that  the  aoCt- 
vare  be  built  in  the  ainiaua  tlae,  tLe  eatiaator  ahouli 
conalder  alternative  aolutlona  that  take  longer  bu*  coat 
leaa.  Th«  vhat-iC  Cuaetioas  srovide  the  anility  to  #xploo 
additional  build  atrateglea  that  take  longer  and  could 
better  auit  the  eatiaator*a  needa.  The  aana^eaent  whet-i? 
octtcna  include* 


<t0 


a.  Design   to   Schedule 

SUA  will  automatically  determine  the  minimum 
time  schedule  foe  which  development  of  the  system  is 
feasible.  This  function  ma 7  be  used  to  set  an  alternative 
schedule  for  development.  A  new  corresponding  cost,  effort 
and   peak  manpower  will  be    provided. 

b.  Design   to  Cost 

This  function  is  used  to  allow  the  user  to  set  a 
new  cost  for  development,  A  new  time  schedule,  level  of 
effort   and    peak   manpower    will   be   generated. 

c.  Design   to   Effort 

This  function  is  used  to  allow  the  user  to  set  a 
new  level  of  effort  for  development.  A  new  time  schedule, 
cost  and  peak   manpower   will    be  generated. 

d.  Design   to   Bisk 

This  function  uses  the  trade-off  law  together 
with  a  user  specified  level  of  risk  of  not  exceeding  a 
required  delivery  date  to  generate  an  expected  development 
time,    level   oi   effort,    cost   and   peak   manpower. 

e.  Design    to    Reliability 

This  function  permits  the  user  to  input  a  speci- 
fied Hean  Time  To  Pailure( HTTF) .  It  then  determines  cue 
appropriate  development  time,  effort,  cost  and  peak  manpower 
to  meet  that  3TTF  together  with  the  estimated  number  of 
errors    and    error   rates. 

f.  Linear   Program 

This  function  uses  the  technique  of  linear 
programming  tc  determine  the  minimum  effort  (and  cost)  or 
the  minimum  time  in  which  a  system  can  be  built.  The  results 
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are      baaed   on      the      actual      manpower,      cost,        and      schedule 
constraints      of        the     user,  combined     with        the     system 

constraints    described   earlier   to   yield  a  constrained  optimal 
solution. 

g.      Best  Bid 

This  function  picks  the  best  time-effort  combi- 
nation by  maximizing  the  joint  probability  that  the  develop- 
ment tise  is  greater  or  egual  to  a  user-  specified  end  date 
and   the   cost    is  less  or  egual   to  a   user-  specified  cost. 

h.      Temporary   Change 

This  function     lets  the   user     temporarily  chance 

up   to  nine   parameters-    title,  start   date,      size,      standard 

deviation  on   size,      labor   rate,  uncertainty  on   labor    rate, 

inflation      rate,      productivity  index     and    manpower     ouiliup 
index. 

Once  tha  estimator  has  found  a  solution  that  best 
•uits  the  estimator's  requirement,  the  estimator  will  need  a 
set  of  detailed  plans  to  implement  the  solution.  By  periodi- 
cally ccaparing  progress  of  the  development  with  the  plan, 
the  estimator  has  toe  means  to  control  all  phases  of  the 
software  development  from  the  oeginning  of  the  feasibility 
study  through  completion  of  operation  and  maintenance.  The 
implementation  options  include: 

a.       Han  loading 

This  function  prcvides  projections  of  the  mean 
number  of  pecc le  (and  standard  deviation)  tnat  will  be 
applied  to  the  project  throughout  development.  These 
projections  are  based  on  an  optimal  application  of  resources 
over  time. 
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b.      Cashflow 

This  function  provides  projections  of  the 
expected  cashflow  on  a  month-to-aonth  basis  througoout 
development    of   the   systea. 

C       Life-Cycle 

This  function  provides  projections  of  the 
expected  aanpcwer  and  cashflow  throughout  the  life-cycle  of 
the  systea. .  Projections  are  provided  on  a  monthly,  quar- 
terly,   cr   yearly  basis. 

d.  Risk  Analysis 

This  function  determines  the  probability  of 
developing  a  systea  within  a  specified  time  or  for  a  speci- 
fied cost,  it  is  very  useful  for  strategic  planning  purposes 
by  providing  the  associated  with  various  tiae  and  cost 
decisions. 

e.  Mcrk   Breakdown 

This  function  shows  a  breakout  of  effort  devoted 
to  specific  skill  categories  as  a  function  of  the  develop- 
ment  schedule. 

t.      Effort   Between  milestones 

This  function  shows  a  breakout  of  effort 
devoted  to  principal  activities  as  a  function  of  the  devel- 
opment   schedule. 

g.       Milestones 

Based  on  a  predetermined  total  development  tiae, 
this  function  provides  a  realistic  schedule  for  the  aajor 
milestones   of    the   project. 
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n.       Code 

Ibis  function  provides  a  rate  of  code  produc- 
tion and  cumulative  code  production  for  valid  end  product 
cost.    Top  down  structured  prograssing   is  assuaed. 

i.      Gantt  Chart 

This  function  provides  a  Gantt  Chart  of  activity 
phases  and  their  respective  silestones.  It  will  reflect 
whether  the  design  and  coding  is  done  in  a  top-down  struc- 
tured sethod  or  with  a  foraal  critical  design  review 
followed  by    a  coding   phase. 

j.      Front-End    Estiaates 

Ibis  function  provides  low,  average,  and  hign 
estisatcs  or  the  tiae  and  effort  reguired  for  the  feasi- 
bility  study   and  design  phase. 

k.      CFO    Osage 

This  function  provides  a  table  of  expected 
aachine  usage  over  the  life  cycle  of  the  systea,  along  witn 
an  estiaate    cf   total   aachine    hours   reguired   for   developaent. 

1.      Reliability 

Ibis  function  gives  projections  of  error  rate, 
cuaulative  errora  created,  found  and  fixed,  and  (lean  riae  To 
Pailure     nontb     by   aonth      until     a      reliability  of      .999     is 

achieved. 

a.       Documentation 

Based  on  tne  total  systea  size  and  data  froa 
hundreds  of  siailar  software  systeas,  a  range  of  expected 
pages  of  docuaenta tion    is  given. 
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n.      Summary  of   Development    Costs 

This   function  prcvidea  a     auaaary  of      the    aajoc 

development    costs  for    the  systen.      These  costs  include    labor 

coats  and     CPU  coats   over  tiae  and   the     total  documentation 
cost. 

o.      Benefit   Analysis 

This  function  coaputes  the  benefit  of  the  systes 
required  to  aaortire  the  cost  of  developaent  and  mainte- 
nance. It  is  based  on  the  anticipated  economic  life  of  the 
aystea  as  well  as  the  average  rate  of  return  for  the 
organization. 

The  SLIfl  aodel  furnishes  an  effective  aeans  to  estiaate 
and  control  the  cost,  schedule  and  manpower  requirements  of 
building  and  maintaining  medium  size  to  very  large  software 
systems.  The  prograa  manager  can  tailor  his  estimates  to 
meet  all  realistic  constraints  imposed  on  the  developaent. 
After  an  intenaive  evaluation  of  the  SLI1  approach,  the 
Department  of  Defense  adopted  the  aethodology  as  the  stan- 
dard macro  estimating  technigoe  to  be  oseo  on  major  software 
systems   in    all    services   and    defense    agencies. 
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▼•    PHQCBDOIZ    AID    DATABASE 

Host  coaacn  aethods  of  software  costing  start  with  esti- 
a at  ion  of  ths  nuaber  of  instructions.  Boshs  [  Ref .  6]  said 
ths  biggest  difficulty  in  using  today's  aigonthas  in  soft- 
wars  cost  aodsls  is  ths  problss  of  providing  sound  sizing 
estisatss. 

Patnaa  fFef.  1]  suggests  that  in  the  systeas  definitxcn 
phase,  ws  dc  estisats  a  cough  idea  of  the  system  size 
(source  statesents)  and  establish  bounds  on  aanpower  effort 
and  derelopaeat  years.  In  the  requireaent  and  specification 
phase,  the  Euifcer  of  files,  reports,  and  application 
prograaa  are  good  estisators  of  the  size  of  the  system  ani 
hence  the  tiae  and   effort   required. 

This  paper  is  an  investigation  of  ways  in  which  we  aight 
be  able  to  estisats  the  size  of  a  new  project,  cased  on 
Putnaa's  existing  data  base  of  close  to  one  tnousar.i 
systeas.  Breakouts  hare  been  wade  of  that  data  base  by 
application  type  and  the  average  size  and  the  standard  devi- 
ation of  each  of  tnose  application  types  has  been  calcu- 
lated. The  estisator  can  be  approached  in  a  Bayesian  sense, 
such  that  if  it  is  a  scientific  systea,  then  it  wouli  fall 
soaewhere  in  the  range  for  a  scientific  systea.  This  would 
be  the  Bayesian  prior.  Then  this  category  is  presented 
graphically,  and  the  person  asked  whether  it  tends  to  be 
toward  the  low  end  of  this  category,  toward  the  high  end  of 
this  category,  cr  low-aiddle  or  high-niddle.  By  doing  son** 
statistical  analysis,  it  is  possible  to  coae  up  with  a 
weighted  expected  value  and  a  new  estisate  of  a  standard 
deviation  }ust  ty  using  the  person's  notional  choice  and  the 
PLBT-sizing    foraula.  This    would   be  a     Bayesian    likelihood 

estiaate;  it  could  be  coabined  together  with  the  prior  Mia] 
Bares'    theorea.        The    usefulness  of    the   Bayesian   approach   to 
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statistical  inference  rests  upon  the  usefulness  of  incorpo- 
rating personal,  subjective  beliefs  directly  into  the 
analysis. 

Proa  Bayesian  inference  and  decision,  it  say  be  seen 
that  the  posterior  probabilities  are  derived  directly  froa 
prior  probabilities  and  the  likelihoods.  It  should  again  be 
recalled  that  the  aean  and  standard  deviation  of  a  nor  sally 
distributed  randos  variable  coapletely  specify  its  prob- 
ability function.  Further,  it  is  easily  provided  by  seans 
of  the  calculus  that  if  the  prior  probability  and  the  live- 
lihood are  both  norsally  distributed,  the  posterior,  prob- 
abilities mst  be  noraally  distributed.  The  reciprocal  of 
the  posterior  variance  (  <f 2  )  is  equal  to  the  sua  of  tae 
reciprocal  of  the  prior  variance  (  $2  )  and  the  reciprocal 
of  the  likelihood  variance  (  4*  )  *  reflecting  the  fact  that 
the  two  sources  of  information  are  pcoled  together.  The 
posterior  aean  (E2  )  is  a  weighted  average  of  the  prior  cean 
(E0  )  and  the  saaple  aeat  (E  ,  ),  the  weights  being  tha 
reciprocals  of  the  respective  variance  [Pets.  16,17],  it* 
equations  are   as   follows: 
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These    posterior   aeans     and  standard    deviations   Mill      he    used 
as   SLI9    input    parameters. 
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1.      QSH    DATA    BASE 

QSH  (Quantitative  Software  Managenent)  ,  Inc.  is  a  company 
foraed  to  help  estiaators  solve  critical  cost  and  schedule 
control  problems  in  business  and  governaent.  The  QSfl  data 
base  is  cosposed  of  one  thousand  systeas  froa  DOD,  RADC  iSose 
Air  Developaent  Center),  US  Aray  Coaputer  Systeas  Coaaar.i, 
and  various  coapanies.  Appendix  G  shows  a  saaple  for  data 
foraat.  The  QS«  data  base  is  coaposed  of  ten  types  as  shown 
in   Table  3. 


TABLE   3 
CSB    DATA    BASE   BI    APPLICATION   TTPE 

Application   Type  So.    Systea  Avj 

systea    size) 

1  Micro    cede/  Pira  ware   data   case  17435    i 

2  Beal-tiae        data   base  125  56670 

3  Avionic    data    base  26  80  186    I 
u   systea    Software   data  base                            75                   75035 

5  Coaaaad   0     Control    data   base  61  oH52    I 

6  T alec 39      lata   oase  32  '42  179    i 

7  scientific     data   base  82  9'*85    i 
6  Process  Control   data  oase  11  52780    | 

9  Business     data    base  547  71t93    I 

10  Unknown   application  1  UOOOO    i 
fixed    Application   data    base                     971  69  549    | 

I 

■ 


Table   4    sho's   tnat    QS!1   data    base   divided   by   size    ranje. 

B.       PBOCEDOBE 

This  idea  is  that  by  partitioning  tne  data  base 
according  to  statistical  sub-qroups,  we  estimate  new  Droject 
size  using  Bayesian  inference.  It  aay  be  possible  to  come 
close  enough  to  the  true  value  to  give  aeaningful  softvire 
estiaates  in  early  feasibility  study  phases  of  a  aajor 
pcolect.     The    procedure  consists  of    five  steps. 
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TABLE    41 
Q3B   DATA    BASE   BT    SIZE    BANGE 


Category  rang*  possible  •  in  OB       Ave. 

I   K)  spread  range  Size 

1   Seell  SK  -15K  IK  -    20   K  274  8296 


2  Sediua                   15K-   35R                   10K    -40   K  241         24437 

3  flediua    Large   35K  -75K                 25k- 125   K  207        53474 

4  Large  75K-  200K  50K-250  K  179  120573 
Very  Large  200K-600K  200K-600K  62  318366 
Extra  Large  600K-1000K  500K-1000K  6  763060 
Super   Large  Bore   than    1000K   750k-1500k  2      1200000 


1-      fifilsxjijtt  A££li£a.tl&fi   lYBfi 

The  different  systee  types  have  unique  properties 
which  have  to  be  considered  so  that  parameters  can  be  tuned 
to  these  properties.  It  is  isportant  to  know  what  kind  of 
software  application  type  will  be  wade.  Osing  each  applica- 
tion type's  scan  and  standard  deviation,  we  get  statistical 
results  fros  tunning  the  SLIM  aodel.  Appendix  A  shots  the 
best  case.  In  the  best  case,  it  is  assuaed  that  tise  is 
estiaated  within  2  percent  and  effort  within  9  percent. 
Appendix  F  shows  the  extrese  case.  In  the  extreae  case, 
tiee  is  estiaated  within  30  percent  and  effort  within  80 
percent . 

2.      Sjtl££l  Silt  CaiSSSIX   AJld  ii§  2i)AJlUl£ 

Project  size  is  a  aajor  factor  that  detersir.es  th? 
level  of  aanaqeaent  control  ar.d  the  types  of  tools  and  tech- 
nique* required  on  a  software  project.  Initially  the  prograx 
■anaqer  Jetereir.es  the  size  category  froa  Table  4  and,  based 
on  the  possible  spread  range,  he  considers  the  overlap  on 
both  sides  of  the  the  category  range.  Proa  application  type 
and  size  range,  the  prograa  aanager  can  choose  the  proper 
aean   and  standard     deviation    cf  software  size      froa   Appendix 
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C.  It  will  be  used  for  Bayesian  prior  estiaates.  For 
•  niplt,  let  os  select  the  category  size  of  large.  For  this 
selection  range  of  75K-200K,  the  overlap  range  is  graphi- 
cally  represented  in   Figure   5.1. 


Figure   5.1        Ihere   it  Fells  ia   the  Bange    (Large). 

Mow    select'  a  size  range  froa  Low,    diddle    Low,    diddle 
High,        High.  issusing      that  the     size     is     approximately 

noraally  distributed,  we  can  use  these  as  Bayesian  likeli- 
hood estiaates.  These  size  ranges  are  also  shown  in  Figure 
5.1.  The  prograa  aaaager  believes  it  falls  in  the  second 
quantile  which  we  call  "Hid  LowN.  osing  weighted  aeans  and 
the  PEBT-sizioq  foraula,  th«  project  aanager  can  get  the 
aaaa  and  standard  deviation   of  software  size. 

S      •     (50    ♦    4(125)    *250)    /   6    ■    133.3    (K) 


d*S 


(    250  -   50    )    /  6    -    33.     (K) 


The   other  size  categories  and   their   respective   guantiles  are 
cep resented    in   Appendix  0. 
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3.      Coapnta  jie_w  AAAA  AA&   Standard   Deviation 

To  get  posterior  teao  and  standard  deviation  as 
input  paraaeters  for  SLIM,  we  ase  the  Bayesian  approach.  We 
ccabine  prior  estiaate  froc  application's  type  and  size  and 
likelihood  estiaate  froa  the  prograa  aanager's  subjective 
belief. 

t.     AAA  AHA 

The  project  estiaates  provide  all  cost,  schedule, 
aanpower,  quality,  and  risk  estiaates  for  a  software 
project.  This  oat  pat  is  used  to  detersine  the  miniaun  tine 
developaent  strategy  and  its  associated  uncertainty.  Once  a 
einiaua  .tiae  solution  is  established  the  prograa  aanager 
should  use  the  aanageaent  what-if  options  to  impose  project 
constraints.  when  an  acceptable  solution  is  obtained,  use 
the  lap  la-sen  tat  ion  reports  and  graphs  to  generate  a  set  of 
work   plans. 

5.    naimi 

To  analyze  the  sensitivity  of  oar  solution  to  varia- 
tions in  the  size,  we  use  the  tenporary  change  routine.  The 
report  for  teaporary  changes  vill  contain  a  suaaary  of  the 
changes  and  a  new  ainiaua  tiae  solution  based  upon  the 
changes.  Results  of  the  ainiaua  tiae  solution  are  output  in 
three  tables.  Ihe  first  table,  the  ainiaua  tiae  solution, 
gives  a  consistent  set  of  aanagaaent  aetrics  (aean  and  stan- 
dard deviation)  for  building  the  systea  in  the  shortest 
possible  tiae.  The  second  table,  a  sensitivity  profile, 
shows  hew  the  aanageaent  metrics  change  as  a  result  of  on* 
and  three  standard  deviation  changes  in  the  systea  size 
(aean).  The  third  table,  a  consistency  cneck,  coapares  the 
estiaator's  solution  with  historical  data  for  systems  of 
coaparatle  size   in   the  QSH  data  base. 


51 


All  the  variables  of  the  software  equation  are 
•abject  to  some  degree  of  uncertainty  and  the  program 
aanager  Bust  have  a  leans  of  taking  this  into  account  in  an 
effort  development  risk  profile.  Putnam  £Ref.  1]  suggests 
risk  analysis  is  probably  the  sost  important  aspect  of  any 
software  systes  analysis.  In  an  uncertain  process,  risk 
analysis  measures  the  uncertainty  to  let  us  develop  proper 
strategies   to   minimize  the  risk. 

C.      IXABPLI 

Let  us  examine  a  scientific  type  example  in  which  a  new 
stand-alone  development  project  will  be  aade.  Initially  the 
program  manager  believes  that  the  project  size  category  Kill 
he  large.  3y  observing  the  graphical  representation  of  ta* 
range,  the  program  aanager  subjectively  estimates  that  the 
project  falls  into  MHid  Low**  range.  For  a  scientific 
"Large"  project,  we  can  derive  prior  estimates  for  the  mean 
and  standard  deviation  of  117389  and  34508  respectively  from 
Appendix  C.  Also  we  calculate  likelihood  estimates  of  seaa 
and  standard  deflation  of  13  3300  and  33000  respectively  from 
Ippendix  0,  where  it  falls  in  the  "Hid  Low"  range.  From 
Bayesian  equations,  we  can  get  posterior  estimates,  as 
follows. 


i_        ^ i_  _i_  _2. 


§       *      34508*        33000*  23850* 


238502  23850* 

■ 117389    ♦    133300   «  125700 

34508*  33000* 
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These  estiaates  vill  be  used  as  SLI3  input  paraaeters.  He 
assuae  that  this  project  uses  average  sanpower  and  produc- 
tivity index.  Pros  running  the  SLIB  aodel,  we  get  the 
axniaua  tise  solution.  Knowing  the  sinisus  developsent  tiae 
and  standard  deviation  give  the  progras  sanager  a  framework 
fros  which  to  plan  and  control  the  software  developsent 
process.  Pros  Table  5,  for  the  sinisus  tise  solution,  the 
progras  sanager  should  consider  the  estiaate  having  a  50 
percent  chance  of  being  realized  upon  completion  of  the 
ays  tea.  when  this  expected  value  is  added  to  its  standard 
deviation,  it  gives  a  new  value  that  has  an  84  percent 
chance  of  being  realized,  Alsc  the  percent  of  expected  valu-3 
of  the  standard  deviation  is  a  aajcr  factor.  Por  this 
exaaple   it   is  as  follows: 

6*t        /      t      ■   2.  1   /    23.4   ■    .089 
d  d 

81     /      E  ■    139   /   516.5    ■    .269 

This  shows  that  developsent  tise  is  estimated  within  9 
percent  and.  effort  within  27  percent  in  ona  standard  devia- 
tion. The  ether  range  resalts  are  shown  in  Appendix  3. 
Appendix  P     shows  it   for   business  applications. 

Table  6  shows  the  corresponding  expect  ad  values  for 
tise,  effort  and  cost  by  increasing  one  and  three  standard 
deviation  of  systes  size.  Also  it  shows  that  a  9  3  percent 
confidence  interval  of  develcpnent  tise  is  between  16.2 
acnth  and   28.2   aonth. 

Table  7  shows  that  if  the  values  shown  are  within  plus 
or  sinus  4  5  percent  of  the  Bean  for  systems  of  comparable 
size  in  the  data  base,  tne  table  labels  then  *s  **in  normal 
ranqe".  otherwise  the  values  will  be  reported  as  either 
greater   than   cr   less  than  the  norsal  range. 
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TABLE   5 
ftlllHDH   TIBB   SOLOTICB 


TtTUIi       Th«*tm   E»»«ol» 


MANASEMENT    MCTfttC 


iv*tch  sizt  (Statemsntsi 

MINIMUM    DEVELOPMENT    TIMS     (MONTHS) 

DEVELOPMENT    CFFQNT     (HANMONTHS) 

DEVELOPMENT    rOST*  (a     IO<>0    *) 
IUNINFLATEDI 
(INFLATED) 


FSAK 


A  (PEOPLE) 


34 


OATEi   20-SEP-t"»O5 
TIMEl       Ill27t46 


EXPECTED   VALUE 

(SOX   PROSASILirv) 

STD    DEV 

--■...,....     ■■  ■ .- 

"  ■  ■  ■  ■ 

12S700 

23830 

23.4 

2.  1 

314. 3 

139. 0 

21 7S 

66S 

2-5*4 

747 

TIB  12 

6 

SEBSITITITT 

PROFILE 

UN INFLATED 

-3    STO    DEV 
-1    STD    DEV 

EXPECTED 
♦1     STD    DEV 
♦3    STD    DEV 

SOURCE    STMTS                    MONTHS 

34130.                                 16.2 
1 0 1 830 .                                 21.3 
123700.                               23.4 
149330.                               23.1 
197230.                               28.2 

MANMONTHS 

COST     (X     1000) 

162. 
386. 
316. 

6  33. 
9113. 

673. 
1607. 
2178. 
2633. 
3762. 

1 

1 

Figure  5.2  shows  the  aajor  ailestone  tine  Cor  the 
current  solution  as  a  statistical  expected  value,  i.e.  ,  the 
value  that  statistically  has  a  50  percent  probability  of  not 
being    exceeded   upon  completion  of   the    main    prograa. 

Table  3  shows  the  probability  ranges  for  effort,  cost, 
and  tiae  froa  1  percent  to  99  percent  —a  broad  enough  band 
to   cover  all    realistic   possibilities. 
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TIB  IE  7 
CONSISTENCY  TABLE 


MANAGEMENT  METRIC 


time  (MONTH8) 

EFFORT  (NANMONTHS) 
AVERAGE  STAFFING  (PEOPLE) 
PRODUCTIVITY  (LINES/MM) 


VALUE 


ASSESSMENT 


--_„_..___ 

23.4 

IN 

NORMAL  RANGE 

31* 

IN 

NORMAL  RANGE 

22 

IN 

NORMAL  RANGE 

243 

IN 

NORMAL  RANGE 

-1    STP   DEU         EXP        +1    STP   PEU 


Figure  5.2       Bisk  Profile    (tiie)  . 

froi  the  tables  and  grapn,  the  prograa  aanager  deter- 
mines the  probability  that  other  tises,  effort,  and  costs 
will  not  be  exceeded.  Development  time  and  ailestones  are 
the  aost  sensitive  eleaents  in  the  process.  Milestones  scale 
linearly,      leaning   that  if  the  project   lanager   is  late   on  an 
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TABLE 

8 

PI0B1BILITI 

PROFILE 

UN INFLATED 

4*08A8IL:TY 

MANHQNTWS 

COST 

(X    «    10001 

Tint    (MONTHS) 

1 

X 

143 

423 

13.4 

3 

X 

2M 

1080 

20.0 

to 

X 

sa 

1322 

20.  a 

20 

X 

400 

1414 

21.7 

30 

X 

444 

iaza 

22.3 

40 

X     ■ 

401 

20O4 

22.4 

30 

X 

314 

2173 

23.4 

40 

X 

332 

23*7 

23.4 

70 

X 

314 

2323 

24.3 

■0 

*• 

453 

27*0 

23.2 

«»o 

V 

443 

3033 

>               24.  1 

43 

X 

7*3 

3274 

24.8 

44 

X 

MO 

3731 

28.2 

early    milestone,        the   project  manager      will   very      likely   be 
late  on     succeeding   milestones.  It   is      important    for      the 

program   manager    to   remember  B cooks*    law:      Adding    manpower  to 
a  late   project   makes  it  later. 
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II.  QMUMU1M  ULB  UCfiJUlUaXIfillS 

la  order  for  the  prograa  aanager  and  his  support  teas 
to  evaluate  a  software  cost  proposal,  they  aust  have  a 
detailed  understanding  of  the  process  that  developed  the 
cost  estisate  and  shoald  have  sose  traceaoility  to  the  vari- 
ances or  sensitivity  of  the  estimating  coaponents.  It  is 
important  for  the  prograa  sanager  to  recognize  the 
sisilarities/differeoces  between  the  defease  systeo  life 
cycle  and  the  other  coaaercial  developaent  life  cycle.  The 
proqraa  aanager  should  coagare  various  cost  acdels  for 
alternative    eatiaates. 

The  life-cycle  curve  can  be  aatheaatically  represented 
by  the  Bayleigh  equation,  which  is  a  good  aanageaent  tcoi. 
Por  planning  and  evaluating  the  developaent  effort  lifa 
cycle,    the   SLIH  aodel   is  a  very  powerful  tool. 

It  is  hard  to  estisate  software  size  in  the  early  phase 
of  systea  developaer.t.  But  the  prograa  aanager  can  estisate 
the  new  project  size  using  Bayesian  inference.  To  get  i 
Bayesian  estiaate  of  software  size*  the  program  aar.ager 
coabines  a  trior  estiaate  fron  application's  type  ar.i 
category  size  with  a  likelihood  estiaate  froa  the  program 
aanager 's  subjective  belief.  When  coabined  with  the  capa- 
bilities of  the  SLIH  aodel,  the  developaent  tiae  is  esti- 
mated within  15  percent  and  effort  within  33  percent  in  one 
standard  deviation. 

This  aethed  couxi  be  a  fruitful  way  to  get  at  the  early 
estimating  prcciea  in  a  gross  way,  yet  good  enough  to  get  in 
the  "ball  park"  of  what  people  need  at  that  phase  of  the 
project. 

Future  research  should  focus  on  the  relationship  between 
cost  attribute   factors  and  systea  application    types. 
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AEEMJ2I2  A 

DISTBIBOTIOI    BT  AFPLZC1TIOI  TYPE  (BEST    CASE) 

Application  Type  Detalopaent   Tiae  Effort 

Bean.      Std.    Da?  Haan.  std.Dev 
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4  ays  tea   Software  18.69  .41  257.0  22.3 

5  Coaaand   6      Control  17.20             .38  192.7  16.7 

6  Telecoa  14.61             .30  108.1  8.8 

7  Scientific  20.31  .45  334.3  26.8 

8  Procasa   Control  16.06             .37  156.1  14.3 

9  Business  18.29              .40  243.8  20.5 
Sixed   Application  18.05            .38  233.5  19.2 
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